Multicast-Enabled Address Resolution Protocol (ME-ARP)

ABSTRACT

A Multicast-Enabled Address Resolution Protocol (ME-ARP) is disclosed. This ME-ARP allows the building of independent IP based Virtual Private LAN segments (VPLS) over a multicast enabled IP backbone using stateless tunnels and optimal VPLS traffic forwarding. Each VPLS has an associated IP subnet which is completely independent from other VPLS or the underlying IP backbone itself. Each Customer Premises Equipment (CPE) device needs only to be configured with a VPLS identifier and its serving IP subnet per VPLS designated interface.

FIELD OF THE INVENTION

This invention relates to a scalable and server-less solution to buildVirtual Private LAN Segments (VPLS) based on a multicast enabled IPbackbone and more particularly to a Multicast-Enabled Address ResolutionProtocol (ME-ARP).

BACKGROUND OF THE INVENTION

The popularity of the Internet is driving requirements for secure andsegregated IP interconnection of remote sites. One solution is to usethe underlying network supporting virtual connections i.e. Frame Relayor ATM. These virtual connections can be separated by provisioning toform a Virtual Private Network which is Layer 3 protocol transparent.However if the underlying network is IP itself, as is the case with theInternet then IP tunnels can be used to interconnect two or more sites.Any other known layer 2 VPN (Virtual Private Network) solution used inthe prior art requires a centralized server where all CPE (CustomerPremises Equipment) and IP devices have to be statically or dynamicallyregistered, like LANE (Local-Area-Network Emulation); NHRP(Next-Hop-Routing-Protocol) or Classical IP.

A need exists for building IP based virtual private LAN segments(sharing one IP subnet) with complete transparency regarding TCP/IP,site-independent CPE configuration and with dynamic stateless tunnels tooptimally forward unicast traffic based on routing and policy per VPLS.VPLS with different Identifiers can use overlapping IP subnets. With themethod of the present invention, a centralized server or a list of CPEdevices configured for each VPN is not required.

SUMMARY OF THE INVENTION

One aspect of the present invention is to provide a scalable andserver-less solution to build Virtual Private LAN Segments (VPLS).

Another aspect of the present invention is to provide aMulticast-Enabled Address Resolution Protocol (ME-ARP). This inventionallows the building of independent IP based Virtual Private LAN segments(VPLS) over a multicast enabled IP backbone using stateless tunnels andoptimal VPLS traffic forwarding. Each VPLS has an associated IP subnetwhich is independent from other VPLS or the underlying IP backboneitself. Each Customer Premises Equipment (CPE) device needs only to beconfigured with a VPLS identifier and its serving IP subnet per VPLSdesignated interface. In addition, each end station connected to aPhysical LAN Segment (PLS) does not need to be modified in order to be amember of the VPLS. No other configuration parameters e.g. list of CPEdevices, their logical or physical locations nor their IP addresses arerequired. The unique invention is ME-ARP (Multicast Enabled AddressResolution Protocol) including the creation of constructed lower layeraddress based on VPN (Virtual Private Network) Id and tunnel endpoint.Advantages provided by the method of the present invention include:

-   -   a) separation of customer IP address space from either the        service provider or another customer determined by policy not to        be in the same virtual private network (VPN);    -   b) capability for a remote site to belong to one or more VPN as        long as the VPN policy allows. To provide support for IPv4 based        applications at this point;    -   c) transparent or Routed VPN's (by use of external routers) can        be constructed independently or combined with this architecture;    -   d) due to the use of an underlying IP multicast network to        forward VPN broadcast traffic in this solution, there is no need        to provide address or broadcast servers; and    -   c) VPN traffic forwarding is achieved via stateless and        optionally secured tunnels which are optimally routed using the        underlying IP network backbone routing architecture.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a is a block diagram illustrating a physical view of a VirtualPrivate LAN Segment (VPLS) network for use with the present invention;

FIG. 1 b is a diagram illustrating a logical view of the network of FIG.1 a or as would be seen from the customer's perspective;

FIG. 2 a illustrates a packet format corresponding to an IPsecAuthentication Header (AH) encapsulation with authentication;

FIG. 2 b illustrates a packet format corresponding to an IPsecEncapsulating Security Payload (ESP) with authentication privacy;

FIG. 3 illustrates a standard ARP packet format on Ethernet;

FIG. 4 is a block diagram of a IP Backbone network for illustrating theME-ARP request/reply packet flow according to the present invention;

FIG. 5 is a block diagram illustrating the transfer of ME-ARP packetinformation between a first and second end station according to themethod of the present invention; and

FIG. 6 is a table illustrating the content of the ARP tables at variouspoint during the transfer of ME-ARP packet information.

Similar references are used in different figures to denote similarcomponents.

In order to facilitate the description of the invention, the followingabbreviations have been used. The terminology used in this document isbased on the definitions proposed by the Internet Engineers Task Force(IETF).

CBT Core Based Tree Multicast Routing Protocol

CPE Customer Premises Equipment

DVMRP Distance Vector Multicasting Routing Protocol

GRE Generic Routing Encapsulation

IGMP Internet Group Management Protocol

LAN Local Area Network

MOSPF Multicast extensions for Open Shortest Path First

PA Provider Address

PIM Protocol Independent Multicast

PLS Physical LAN Segment

VPN Virtual Private Network

VPLS Virtual Private LAN

UVIP Unnumbered VPN Internet Protocol

The term “Client Address” (CA) space or network ranges is used todescribe the IP address space used by each VPN customer.

The term “Customer Premises Equipment” (CPE) defines an edge device(e.g., router, etc.), fully managed by the provider, connecting acustomers PLS to its VPN.

The term “Provider Address” (PA) space or network ranges is used todescribe the provider allocated IP addresses in his IP backbone. (e.g.,Tunnel endpoints have an address assigned out of the PA range).

The term “Physical LAN Segment” (PLS) is used in this document todescribe a broadcast domain, like a shared or switched ethernet segment,connecting hosts, servers and routers at each site. Without the use of aVPN technology, the scope of these PLS is limited per site.

A Virtual Private LAN Segment (VPLS) is the emulation of a LAN segmentusing Internet facilities. A VPLS can be used to provide what issometimes known as a transparent LAN service, which can be used tointerconnect multiple CPE nodes. It can be seen as a pure layer 2bridged VPN solution.

The term virtual private networks (VPN) is widely used as a commondescription for any kind of network built over another network withlimited scope.

The term “Unnumbered VPN IP” (UVIP) interface is used in VPLS todescribe the tunnel endpoint connecting a PLS on a first site with allother PLS per VPN. In the scope of the customer's PLS, this interfacedoesn't need to have an IP address assigned to forward traffic (VPLS isa layer 2 VPN solution). The tunnel endpoint itself must have an IPaddress assigned, out of the providers address space.

DETAILED DESCRIPTION OF THE INVENTION

In order to take advantage of all the features of the present invention,it is assumed that the providers of IP backbone services are IPmulticast capable. Similarly, it is assumed that CPE devices are able tojoin a multicast group using IGMP. It is not a requirement that allrouters in the backbone have multicast capabilities. It is possible tointerconnect the CPE devices via a partially meshed or “star-like”multicast backbone, built using a mix of multicast routing protocols andtunnels to interconnect multicast islands. IP multicast is used toforward broadcast and multicast traffic and for IP address resolution,but not for forwarding of unicast traffic.

Referring now to FIG. 1 a, we have shown the physical view or serviceprovider's view of a Virtual Private LAN Segment (VPLS). The IP backbone10 and CPE devices 11, 12, 13 and 14 are managed and typically owned bythe service provider. CPE devices 11-14 are typically comprised ofrouters, whereas each PLS is typically comprised of several IP capabledevices such as end stations (ES1, ES2, etc.)

FIG. 1 b is a diagram illustrating a logical view of the network of FIG.1 a or as would be seen from the customer's perspective. Whereas in FIG.1 a the CPE devices are visible from the provider's perspective, LANsegments are transparent to the customers as illustrated in FIG. 1 b.Similarly, CPE devices which are seen by the service provider areinvisible to the customer.

Stateless tunnels or links are used in CPE (Customer Premises Equipment)between connected sites. The remote tunnel endpoint address informationis directly mapped into the link layer address. ME-ARP is used for IPaddress resolution inside a VPLS. As a result, VPN connected IP deviceswill keep all relevant information about the destination tunnel endpointand VPN membership in their own address resolution (ARP) table. Specialunnumbered IP LAN interfaces will generate the link layer address basedon a configured VPN identifier and dynamically learned tunnel endpoints(via ME-ARP).

Again, as illustrated in FIGS. 1 a and 1 b, a VPLS can span two or moresites, with all IP devices sharing the same IP subnet. The IP addressand mask are chosen by the customer without any restrictions in relationto the provider or other customers. The CPE devices, managed by theprovider, are transparent to the customer. This type of layer 2 VPNsolution possesses the following benefits for the customer:

-   -   Transparency. No IP addresses must be given to the provider;    -   Flat IP subnet. The VPN can be seen as a VPLS, with transparent        support for broadcast protocols like DHCP/BOOTP (Dynamic Host        Configuration Protocol/BOOTstrap Protocol), Netbios/IP etc; and    -   Broadcast and Multicast support. The customer can extend the VPN        with their own routers and run any routing protocol over the VPN        without any coordination with the provider.

Each VPLS has a provider wide unique IP multicast address assigned. AUVIP interface of a CPE device, shown at reference numerals 15, 16, 17and 18, configured for a particular VPLS, will join the VPN's multicastgroup by using IGMP. All broadcast traffic is then encapsulated andforwarded to the VPN's IP multicast address. There is therefore no needfor a central database to keep track of all UVIP interfaces joining acustomer's VPN. This is handled by the IP multicast membership.

In order to forward IP unicast traffic, an enhanced version of proxy ARPis used. The differences from the standard proxy ARP are:

-   -   a) all ARP requests matching the customers IP subnet are        encapsulated and forwarded to all VPN members by sending them to        the VPN's IP multicast address. Note: The CPE device cannot        determine, if an IP device is connected to the local physical        segment or not.    -   b) a forwarded ARP request, after decapsulation, will replace        the source hardware address (MAC, Media-Access-Control or        physical Address) not with the routers own interface MAC        address, but by a calculated address containing the tunnel        source IP address, an interface unique VPN Id (e.g. VPN instance        Id) and a CPE Id (to avoid loops in case of CPE redundancy).

The result of this “multicast enhanced ARP” (ME-ARP) process is that thecustomers IP devices will keep all relevant information about thedestination tunnel endpoint and VPN membership in their ARP table. Thereis no overhead involved, if compared to a real physical IP subnet.

Unique VPN Identifier

Each VPN has a unique identifier assigned. For VPLS built of more thantwo physically separated sites this is a valid IP multicast address. Aseach VPN has a unique IP multicast Id assigned, IGMP and any multicastcapable routing protocol (DVMRP (Distance Vector Multicast RoutingProtocol), MOSPF (Multicast Open Shortest Path First), PIM (ProtocolIndependent Multicast), are used by a configured IP VPN interfaceconnecting a Physical Segment to join the VPNs multicast group.

Individual CPE devices are configured as follows:

Based on the VPLS membership using IP multicast, there is no need for acentral VPN membership database or protocol to distribute thisinformation. It is enough to configure a new VPN member (physicalsegment) in the connecting CPE device. The following minimal informationis configured per UVIP (Unnumbered VPN IP) interface:

-   -   a) VPN IP multicast Id;    -   b) IP Network/Mask. Assigned by the customer from the Client        Address (CA) space. This information is used to determine the        correct VPN, based on either source or destination IP address.        This is important to support multi-netting on the same physical        interface with many VPNs;    -   c) Tunnel IP address. This address from the Provider Address        (PA) space is used to forward VPN traffic over the IP backbone        to the correct tunnel end-point (bound to a VPN interface). The        VPN identifier in each encapsulated packet can be used to        identify the correct logical UVIP interface inside the CPE        device;    -   d) MAC calculation algorithm. This optional, but recommended,        configuration parameter allows the support of different MAC        address calculation to prevent possible duplicates.

Referring now to FIGS. 2 a and 2 b, in the preferred embodiment of theinvention, depending on the security requirements, three differentencapsulation formats can be used: without security, with authenticationonly or with encryption. The encapsulated methods are based on IPsectunnel mode [RFC2401 . . . RFC2406]. The IP2 header contains the IPsource and destination address from the providers address space (tunnelendpoint IP addresses or address as destination address). The IP1 headeris the original IP packet header.

In FIG. 2 a, we have shown an IPsec AH encapsulation (withauthentication). FIG. 2 b shows an IPsec ESP encapsulation (with auth.privacy).

IP multicast and broadcast packets are encapsulated and tagged with theVPN multicast Id in the SPI field of the IPsec AH/ESP header andforwarded to the VPN IP multicast address (equal to VPN multicast Id).All active members of the VPNs multicast group receive the encapsulatedpacket and forward it to the appropriate VPN's UVIP interface.

Referring now to FIG. 3, we have shown an ARP Request/Reply packetincluding Ethernet transmission layer. In FIG. 4, we have shown a blockdiagram of an IP Backbone network and in FIG. 5, we have shown a blockdiagram illustrating the transfer of packet information between a firstand second end station, respectively.

In operation, with reference to FIGS. 3, 4, 5 and 6, end station A wantsto send an IP packet to end station B on the same logical subnet butconnected to different gateways. It is assumed, that the ARP tables 80and 81 from both end stations are empty. Therefore end station A sendsan ARP request 50 to the ethernet broadcast address 51. CPE A,configured with the proper VPN information, checks the source IP address52 of the ARP request packet 50 against its UVIP interfaces configuredon the physical interface. In case of a match, it encapsulates thewhole, unmodified, ARP request 50 into an IPsec packet 55 including theVPN identifier 56 (equals assigned IP multicast address) and forwardspacket 55 to the VPN's multicast address 57 using the configured localIP tunnel-endpoint 58 as source address. CPE A also adds a local ARPentry for end station A in its ARP table 72 for that UVIP interface.(CPE A will forward the ARP request, even if end station B is connectedto the same physical network).

All CPEs joining the VPN will receive this encapsulated ARP request,unpack it, and forward out the local UVIP interface with the followingmodification to the original ARP request 55:

-   -   replace the original HW source address 59 (MAC address from end        station A) with a calculated MAC address containing the tunnel        end-point IP address from CPE A(=source address from the        received IPsec packet) and an optional interface unique VPN Id.

This new HW source address 60 is replaced in the ethernet header as wellas in the ARP packet 61.

CPE B might add an entry to its ARP table 83 for caching. End station Breceives the ARP request 62 and respond to it with a normal ARP replycontaining its physical HW MAC address 64 as source in the ethernetheader and in the ARP reply packet 65. An ARP entry for end station Awith the source MAC address from the ARP request is added on end stationB. The ARP table 81 of end station B now contains an entry for endstation A with a constructed MAC address containing the tunnel-endpointIP address and VPN Id. CPE B, configured to listen for constructed MACaddresses, identifies the ARP reply 63 from end station B by checkingthe source MAC address 64 as well as the source IP address 66 (part ofVPN's IP network), encapsulate and forwards the ARP reply 67 directly tothe addressed tunnel endpoint (extract tunnel endpoint IP address fromdestination MAC address).

CPE A decapsulates the ARP reply packet 67, checks the destination ortarget IP address 68 and replaces the destination or target MAC address69 with the address found in its local ARP cache, and sends theconstructed ARP reply 70 out to end station A on the local attachedphysical LAN segment. In addition, the source MAC address 71 (in theEthernet header and ARP packet) is replaced with a constructed MACaddress 72 containing an optional interface locally unique VPN Id andthe IP address of CPE B (where the ARP reply came from).

If the ARP table 82 from CPE A does not contain an entry for end stationA, then CPE A will have to send an ARP request out for end station Awith end station B's IP address before forwarding the ARP reply packetout to end station A.

Finally, end station A receives the ARP reply packet 70 and builds anentry in its ARP table 80 with an entry for end station B and the MACaddress containing the remote tunnel endpoint IP address and VPN Id.

1-10. (canceled)
 11. A method for enhancing an address resolutionprotocol, the method comprising the steps of: assigning to a virtualprivate local area network (“VPLS”) a virtual private network internetprotocol multicast address that is unique to the VPLS; joining anunnumbered virtual private network internet protocol (“UVIP”) interfaceof customer premises equipment (“CPE”) with a multicast group of avirtual private network (“VPN”) using an Internet Group ManagementProtocol (“IGMP”); encapsulating a traffic; and forwarding theencapsulated traffic to the VPN internet protocol multicast address. 12.The method according to claim 11, further comprising keeping track ofthe joined UVIP interface of the CPE using the VPN internet protocolmulticast address.
 13. The method according to claim 11, wherein thestep of joining further includes joining the UVIP interface of the CPEwith the multicast group by using the IOMP with a multicast-capablerouting protocol.
 14. The method according to claim 13, wherein themulticast-capable routing protocol is selected from the group consistingof: a Distance Vector Multicast Routing Protocol (“DVMRP”); a MulticastOpen Shortest Path First (“MOSPF”) protocol; and a Protocol IndependentMulticast (“PIM”) protocol.
 15. The method according to claim 11,further comprising configuring the CPE with configuration informationfor the UVIP interface of the CPE, the configuration informationincluding at least one of a virtual private network multicast IDassociated with the internet protocol address of the VPLS, an internetprotocol network mask, and a tunnel internet protocol address.
 16. Themethod according to claim 15, wherein the configuration informationfurther includes a media-access-control (“MAC”) address calculationalgorithm.
 17. The method according to claim 11, further comprising:encapsulating an address resolution protocol (“ARP”) request matching acustomer's IP subnet; and forwarding the encapsulated ARP request to theVPN internet protocol multicast address of the VPLS.
 18. The methodaccording to claim 17, further comprising: receiving a forwardedencapsulated ARP request; decapsulating the received encapsulated ARPrequest; replacing a source hardware address of the decapsulated ARPrequest with a calculated address containing a tunnel source internetprotocol address, a virtual private network identifier and a customerpremises equipment identifier.
 19. The method according to claim 11,further comprising creating an entry in an address resolution protocoltable (“ARP table”) for caching, wherein the ARP table is associatedwith the CPE.
 20. The method according to claim 11, wherein the trafficis encapsulated in a format selected from the group consisting of:encapsulation without security; encapsulation with authentication only;and encapsulation with encryption.
 21. A system for enhancing an addressresolution protocol, comprising: at least one memory; at least oneprocessor coupled to said at least one memory and including an addressassigner operable to assign to a virtual private local area network(“VPLS”) a virtual private network internet protocol multicast addressthat is unique to the VPLS; an internet group manager operable to joinan unnumbered virtual private network internet protocol (“UVIP”)interface of customer premises equipment (“CPE”) with a multicast groupof a virtual private network (“VPN”) using an Internet Group ManagementProtocol (“IOMP”); an encapsulater operable to encapsulate a traffic;and a forwarder operable to forward the encapsulated traffic to the VPNinternet protocol multicast address.
 22. The system according to claim21, further comprising an address tracker operable to keep track of thejoined UVIP interface of the CPE using the VPN internet protocolmulticast address.
 23. The system according to claim 21, wherein theinternet group manager is configured to join the UVIP interface of theCPE with the multicast group using the IOMP with a multicast-capablerouting protocol.
 24. The system according to claim 23, wherein themulticast-capable routing protocol is selected from the group consistingof: a Distance Vector Multicast Routing Protocol (“DVMRP”); a MulticastOpen Shortest Path First (“MOSPF”) protocol; and a Protocol IndependentMulticast (“PIM”) protocol.
 25. The system according to claim 21,further comprising a CPE configurer operable to configure the CPE withconfiguration information for the UVIP interface of the CPE, theconfiguration information including at least one of a virtual privatenetwork multicast ID associated with the internet protocol address ofthe VPLS; an internet protocol network mask; and a tunnel internetprotocol address.
 26. The system according to claim 25, wherein theconfiguration information further includes a media-access-control(“MAC”) address calculation algorithm.
 27. The system according to claim21, wherein: the encapsulator is operable to encapsulate an addressresolution protocol (“ARP”) request matching a customer's IP subnet; andthe forwarder is operable to forward the encapsulated ARP request to theVPN internet protocol multicast address of the VPLS.
 28. The systemaccording to claim 27, further comprising: a receiver operable toreceive a forwarded encapsulated ARP request; a decapsulator operable todecapsulate the received encapsulated ARP request; an address replaceroperable to replace a source hardware address of the decapsulated ARPrequest with a calculated address containing a tunnel source internetprotocol address, a virtual private network identifier; and a customerpremises equipment identifier.
 29. The system according to claim 21,further comprising an address resolution table entry creator operable tocreate an entry in an address resolution protocol table (“ARP table”)for caching, wherein the ARP table is associated with the CPE.
 30. Thesystem according to claim 21, wherein the traffic is encapsulated in aformat selected from the group consisting of: encapsulation withoutsecurity; encapsulation with authentication only; and encapsulation withencryption.